NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/566

Text File | 1996-08-06 | 6.3 KB | 137 lines

Path: chronicle.mti.sgi.com!austern
From: James Kanze US/ESC 60/3/141 #40763 <[e-mail]>
Newsgroups: comp.std.c++
Subject: Re: Destruction of singletons
Date: 27 Feb 1996 10:45:03 PST
Organization: -
Approved: [e-mail]
Message-ID: <[e-mail]>
References: <4fvng1$[e-mail]> <4go9au$[e-mail]> <[e-mail]> <4gtmg0$[e-mail]>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: Tue, 27 Feb 96 12:24:42 +0100
In-Reply-To: [e-mail]'s message of 26 Feb 1996 18:08:20 PST
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBVAwUBMTNRR0y4NqrwXLNJAQGRCgH+Kxq9IZ+ecNCH2hQLvfk0SDGv9UAV9NxT
    UvncC1mzxZERHQojhZsPQukpC5FgI5oR39Lms8ptN1c1hT1NIorkig==
    =A/LF
Originator: [e-mail]

In article <4gtmg0$[e-mail]> [e-mail] (Jamshid
Afshar) writes:

|> In article <[e-mail]>,
|> James Kanze US/ESC 60/3/141 #40763  <[e-mail]> wrote:
|> >In article <4go9au$[e-mail]> Jamshid Afshar
|> ><[e-mail]> writes:
|> >
|> >1. As long as there is an active pointer to the memory (a static
|> >pointer), Purify will not classify it as a leak.

|> You're right.  I thought there was some kind of report of all unfreed
|> memory at program exit.

I think you can get a report of all unfreed memory, too, although it
isn't classified as a leak or a potential leak.

|> >In general, I would stress that the prefered solution is to not use
|> >the singleton object in any destructors, and use a local static to
|> >initialize the pointer.  If you do have to use the object in
|> >destructors, however, I would still prefer not destructing it to
|> >trying to manage the `order of destruction' problem (given that most
|> >compiler implementors still consider the order of destruction of
|> >static locals undefined).

|> I agree I would rather have the compiler manage the destruction,
|> especially since it's so easy for them to do it (just generate a
|> "destroy" function and register it with atexit() when the constructor
|> returns).

This would be one solution.

All of the solutions involve dynamic ordering; i.e.: some sort of
registration when the object is constructed.  At present, all of the
compilers I know of use static ordering for the destructors, with just
a simple flag to indicate whether the local static was constructed or
not.

|> >|> Actually, the construction and destruction of "local objects of static
|> >|> storage duration" is not the same as objects outside of functions.  In
|> >|> fact, it seems local statics are more poorly specified.  According to
|> >|> the April '95 Draft, while they are guaranteed to not be constructed
|> >|> until (and if) the function is called, exactly when the destructor is
|> >|> called is unspecified.
|> >
|> >I actually believe that it is, and in fact, has been well defined from
|> >the ARM.

|> Okay, I see now that I was misreading section 6.7 Declaration
|> Statement in the ARM and April 95 Draft.  I took the sentence "Exactly
|> when is unspecified" to mean the destructor order is *completely*
|> unspecified.  I guess the sentence is only referring to the previous
|> sentence (ie, "Whether the destructor is called before or as part of
|> the atexit() functions is unspecified.").

|>    5 The destructor for a local object with static storage duration will be
|>      executed if and only if the variable was constructed.  The  destructor
|>      is  called  either  immediately  before or as part of the calls of the
|>      atexit()  functions  (_lib.support.start.term_).   Exactly   when   is
|>      unspecified.

|> >In any case, the Jan. 96 draft makes the question moot, since it
|> >explicitly adds the words in the destructor section clarifying that
|> >static means both local and non-local.

|> I assume you're referring to 3.6.3 Termination (analogous to ARM 3.4
|> Start and Termination).  Btw, has the wording in 6.7 been changed or
|> improved?  There seems to be some conflict with it and 3.6.3 wrt the
|> order of static destructors and atexit() calls.

Correct.  I've now got it on line, and in fact, it is better than I
remembered, since it also definitly states that the order is
determined by the completion of the constructors.  (For some reason, I
remembered this as being vague.  I was wrong.)

    Destructors for initialized objects of static storage duration
    (declared at block scope or at namespace scope) are called when
    returning from <B>main</B> and when calling <B>exit</B>.  These
    objects are destroyed in the reverse order of the completion of
    their constructors.  For an object of array or class type, all
    subobjects of that object are destroyed before any local object
    with static storage duration initialized during the construction
    the subobjects is destroyed.

Note the words in the first parentheses; this makes it quite clear
that the ordering holds over both local (block scope) and non-local
(namespace scope) variables.

|> >|> [...] What should
|> >|> have been required IMO is that local statics be destroyed in the
|> >|> reverse order they were (fully) constructed.
|> >
|> >I agree.  The remaining weak point in the standard is that it doesn't
|> >really specify what is meant by the ordering, entering the
|> >constructor, or leaving it.

|> If the Standard does not require local statics to be destroyed in the
|> reverse order they were *fully* constructed, local statics are useless
    [...]

Agreed.  This was my mistake: the current (Jan. 96) draft does
guarantee exactly what you (and I) want.

Now if I could only convince them to require static initialization (of
non-local statics) to take place before main:-).

--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:[e-mail]
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:[e-mail]
]